COMMENT ⊗   VALID 00012 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	This file is a compendium of comments received concerning the
C00004 00003	QUESTIONS CONCERNING PHILOSOPHY OF THE HAL SYSTEM
C00015 00004	QUESTIONS CONCERNING IMPLEMENTATION
C00024 00005	SUGGESTIONS FOR NEW FEATURES
C00028 00006	WORDING AND CLARIFICATION SUGGESTIONS
C00034 00007	CONFUSION ABOUT FORCE AND FREE
C00037 00008	COMPLAINTS ABOUT PLANNING
C00039 00009	COMPLAINTS ABOUT EXECUTION
C00041 00010	DISCOMFORT WITH THRUST OF LANGUAGE
C00045 00011	ORDERING IN THE DOCUMENT
C00046 00012	QUESTIONS ABOUT SPECIFIC CONSTRUCTS, AND THEIR MEANINGS
C00048 ENDMK
C⊗;
This file is a compendium of comments received concerning the
HAL paper.  Please add your comments and identify yourself!
QUESTIONS CONCERNING PHILOSOPHY OF THE HAL SYSTEM
	factory can afford 10?
	RF: It seems reasonable that a large factory could eiter
afford a 10 or could subscribe to a timesharing firm.  The 10 need
not be dedicated to HAL; on the contrary, it is more realistic to
assume that general timesharing would be employed, with the computer
being used for accounting, design, and factory scheduling/inventory
work as well.
	LOU: You need the 10 for planning, timesharing only.
We should be able to load a program into the 11 from disc or paper tape
and run it without the 10, that is a precompiled program. Could also
mention that the Hal compiler could be recoded as a multi pass 11 program?
	RCB: Do you forsee an 11 system with enough stuff (symbol table
pointing into the attach-graph-structure, etc.) to allow the user to
slightly modify  the location of a frame (eg. if he notices a drift)
WITHOUT going back thru the 10?  Presumaly the user can interact with
such a canned program (eg. to restart it after an error) without going
back thru the 10.  Ray ... I'm not sure what is reasonable without the
10.

	do you want software servoing, or does hardware often
suffice?
	RF: The range of conceivable tasks is large enough that
hardware servoing cannot in general suffice.  The reason for this is
that hardware servoing restricts use to one of a small number of
modes (typically position, velocity, force servoing), and has no
provision for motions of accomodation or motions whose modes might
change in midstream due to some software-detectable condition. The
advantages of software servoing seem to be these: It is possible to
program the manner in which feedback is to be used.  It is easier to
interface new types of sensors.  It is possible to modify the servo
while the arm is in motion.  It is possible to supply the driving
program with information concerning the success of the motion as well
as to keep it up-to-date on the arm status.
	LOU: There are some clearly distinguisable modes of servoing
that could be translated into hardware, however the hardware becomes
complicated as the computer needs to be able to switch modes as the
program is being executed. There is not much saving in compute power
as the computer needs to perform a servo calculation in order to 
understand what the manipulator is doing and to interact with the 
task. Even in cases of "gross" motion when some compute power can be
saved all the compute power to perform "fine" motions will be available
doing nothing. One advantage gained would be the elimination of quantizing
noise and limited bandwidth due to sampling. These can be provided by
the addition of a high frequency parallel feedback path.

	textual as opposed to spoken/joystick input puts a burden on
the programmer (must be able to type, learn the syntax)
	RF: This is true.  We hope that the supervisor level of HAL
will be simple enough that learning by showing will be natural.  We
do not have joysticks, and therefore currently depend on releasing
brakes and manually moving the arm.  We do not have facility for
vocal input, and therefore currently depend on typed input.  However,
neither of these restrictions is central to the design of HAL, and it
is fairly easy to see how addtional features such as joysticks and
vocal input could be interfaced into the system.  But it is important
to note that there are levels of complexity which are much more
readily transmitted from man to the machine through the interface of
symbolic text.  Complicated motions of two arms simultaneously,
specifications of what conditions to be alert to during an action are
more likely to be unambiguously stated through the medium of text, if
for no other reason than the structure imposed on the textual
language forces a consistent frameword on the initially less
structured intuitive ideas. To provide for general spoken input would
require significant advances in the fields of speech recognition and
language understanding.
	LOU: I Agree with RF.

	assume that bulk of man-machine interaction is symbolic.
	LOU: And graphical, as is practically all engineering design
and specifications.

	assume large comutational facilities necessary and will be
available.
	LOU: We believe that the timesharing/mini approach is the
wave of the future, however the timesharing part could be put on the
mini if necessary to produce a, slow, difficult to modify, look ma
hal in 8K, you dont need a data base just punch a paper tape, system

	assume need impressive user services (sequencing, collision
avoidance, general "guessing games")
	LOU: I dont think that these are necessary but should be
part of RHT's thesis, for the same reason that we left out sensory feedback
and only put in those things that we have done already.
	RCB: Sequencing and general "guessing games" would be nice to have,
but not necessary.  Some sort of collision avoider, on the other hand,
is needed no matter how an assembly is specified: (1) a person physically
moving the arm thru the motions, (2) a person specifying the desired end
point (and via points) for a motion, or (3) a program planning everything.
The criticism is evidently aimed at the relative difficulty of using the
various systems.  In fact, they are probably correct in saying that it
will be harder for a user to predict the path of the arm in case (2) than
in case (1).  It is not always clear to ME what the system is going to
plan for the trajectory from point A to point B.  So, HAL without a
collision avoider assumes that the user (person or program) can determine
where the arm will go.  This means we "need" a collision avoider.  This
gets into the whole argument about whether it is better to plan or step thru
things at run time.


	assume threshold tests suffice for assembly with sensory
feedback.
	RF: In many cases, threshold tests do suffice: To tell if the
arm has hit something, a threshold test on directed force works. To
tell if a screw is binding, a similar test serves.  It is, however,
quite true that in general, such tests lack the ability to modify
trajectories based on the strength of some signal.  This lack is only
partially filled in HAL by the ability to disable and enable
ON-monitors during the course of a motion.  It is our hope eventually
to include the capacity for including devices such as wrist force
sensors in the servo control loop in a programmable fashion.  Our
research has not yet delved into this fascinating prospect, and we
hesitate to include a facility in the language which we do not
understand very well.  When we have a firmer grip on the subject
(which includes the general class of motions of accomodation) we will
no doubt modify the language accordingly.
	LOU: I agree with RF, mabye some snide remark about how Draper
has failed to produce any experimental results etc.
	RCB: Go get'm Lou.




QUESTIONS CONCERNING IMPLEMENTATION
	how does servo predictor find consecutive time slots?
	RF: Perhaps this was not clear in the text.  The predictor
merely requests a time slot for its next awakening.  It has an idea
of how soon it would like to awake, and how long it is willing to
wait if its preferred time has already been reserved by some other
process.  The time-slot sheduler finds a suitable slot in the
calendar and gives it to the requesting servo predictor.  There is no
need to get a slot consecutive to any other one in particular; it is
assumed that a servo can complete its actions within one time slot.
If the scheduler cannot satisfy the request, then it is likely that
the system is overloaded (for example, three arms working
simultaneously will probably overload our currently planned system).
It will find the first slot it can, but this will very likely degrade
servo performance.  (Experience shows that a fast-moving joint needs
to be servoed on the order of at least fifty times every second).
	LOU: When a joint servo has finished servoing a joint it
requests a time slot after some time in the future. The scheduler
returns the first free slot after that time. When the servo gets the
slot it predicts the set points, and feeds forward terms and
everything that it will need to servo with a minimun of delay when it
wakes up again. As the system becomes more heavily loaded the rate of
servoing will drop but not die, indicating the limits of the system.

	Are we using structured programming techniques?
	RF: We are using PAL, which is not a structured language, but
is rather an assembler.  Our approach, however, is structured in a
bottom-up fashion: Our first priority has been to write the memory
management scheme and the timing software, and assuming that these
work, we have been constructing the interpreters and the servos.  We
divide all tasks into reasonably sized subroutines, so in that sense
we are using structured programming.  The principal way in which we
are hurt by not using a higher level language is memory use
conflicts, which have been partially resolved by register usage
conventions and standard macros for dealing with structured data.

	why not use DEC 11 software, like RSX-11?  
	LOU: We probably should have used DEC software and have
written in a higher level language but tough luck.

	what is minimum 11 configuration necessary?
	RF: We are using floating point hardware, which necessitates
the use of either a /40 or a /45.  We plan to use special paging
hardware developed at SAIL, but this will not be critical; other
large-scale memory management is certainly possible.  We cannot yet
predict how much memory will be necessary; it may turn out that a
small disk will be required for 11's with small memories.
	LOU: I do not like the use of the paging hardware for the
standard hal system, we should live in 28k, although I think a disc
is reasonable to hold the program. If we add vision then a special
system might need to use the paging.

	how are discrepancies between planned and real values
discovered?
	RF: This should be clarified in the paper.  The principal way
in which discrepancies crop up is through reading the location of an
arm and using the value to update a variable.  Since the one thing
that the compiler cannot control is the actual location of the arm
after such a motion as a center, a search, or any motion which may
terminate prematurely, those objects attached to an arm are likely to
have run-time locations different from the planned ones.

	how are plans modified to accomodate discrepancies?
	RF: The paper should bring together the several partial
discussions of this topic.  Before a motion begins, all the
intermediate frames are evaluated, and the planned trajectory is
modified to assure that it wil pass through the desired locations.
Since a trajectory is built of polynomial segments (a separate set
for each joint), this modification amounts to addition of a
polynomial correction.  We use fifth degree polynomials to make the
beginning and end of each corrected segment have the same velocity
and acceleration as planned.


	how can you implement loops and procedures and maintain
planning values?
	RF: Across procedure calls, many variables will lose their
planning values, namely, those which the procedure can modify, those
attached to ones which the procedure can modify, and all parameters
which are passed by reference.  The algorithm which propagates
planning values across loops is quite complicated; it attempts to
retain as much planning information as possible.
	LOU: I believe that we can only implement a class of
procedures and loops which leave the world in a predictable state,
such as a procedure to pick up a screw and to screw it into any one
of the six top pump holes.

	If a motion can be stopped on time, distance, force, then
does one have priority, or does motion stop as soon as one is
tripped?
	RF: Any cause for stopping a motion will have its effect as
soon as it triggers.  The time criterion is built into the
trajectory; it manifests itself usually as a destination-encountered
test, not a time test.  Distance and force are actually on-monitors
which repeatedly are tested during a motion.
SUGGESTIONS FOR NEW FEATURES
	need general I/O with arbitrary devices (effectors, sensors,
storage devices), e.g. "effector[3] ← 2*sensor[2]"
	RF: This is an interesting idea which extends the pdp11
notion fo the unibus.  Unnfortunately, the level at which arithmetic
statements are implemented (that is, as interpreted code) makes it
generally infeasible to use such means to control devices requiring
frequent service.  It would be necessary to put such programmed
servoing into a much tighter loop.  We intend evenually to allow
user-programmed servoing, but since we do not understand it very
well, we currently use language-supplied programmed servoing, with
parameters such as force and free that can be user-specified.
	LOU: We will use the operate command.

	do we have USING WOBBLE?
	RF: No, but we probably want it.
	LOU: Everybody needs WOBBLE!
	RCB: I agree!

	need data logging ability (trend analysis, drift detection)
	RF: I definitely agree.  We do not explicitly preclude it in
HAL, but we do not yet make special arrangements for it.
	LOU: This should be in. Someone should findout what is needed.
	RCB: A general statistics gathering mechanism would be nice.  For
example, if the arm moves to a position and centers to grasp a part, it would
be nice to be able to say "monitor the adjustments being made in the
centering and if they drift (as indicated by a change in the average
of the last 20 grasps) correct the set point to match more closely the
actual position of the parts."  This implies some sort of array storage
if various statistics are to be computed ... (eg. standard deviation).
It certainly seems possible to encorporate this type of thing in the
graph structure ... even going so far as to adjust different types of
things (frames or a displacement from a frame).  For example, if the
destination in "MOVE YELLOW TO X + DX" drifts, one could change X (and
all other destinations depending upon X) or just DX.
	Right now there is not even a way that a user could explicitly
save information from assembly to assembly, much less modify things
by any statistics based upon such data.
WORDING AND CLARIFICATION SUGGESTIONS
	p23l1: vector → end point of vector

	need to change name.  HAL/S property of Intermetrics /NASA.
	LOU: I like HANDY but is it being used?
	RCB: SPAS ... Stanford Programmable Assembly System 
		(pronounced `SPAZZ')

	asserts are never explained.  For example, are FITS INTO
reserved words?  Does the compiler really understand them?  Does the
compiler create some ASSERTS itself?

	Def. of TRANS (p.23) opaque. Use many terms before defined.

	we confuse principal and principle.

	Example of COMPILE ERROR is confusing.  Why would you ever
need this?
	RCB: This is used whenever a user wants to make sure that
the world satisfies some predicate, before bothering to continue
planning.  This is especially useful when a `general purpose' segment
of code is written (eg. a procedure), using some assumption about
the world (eg. that the screwdriver is already in the hand).  Since
the code segment probably doesn't make any sense if the assumption
is false (ie. the screwdriver is not in the hand), then trying to
incorporate this code into the plan may be nonsense.  The COMPILE_ERROR
statement provides a way for explicitly stating assumptions about
the world and specifying the error message returned if such assumptions
are not true.  If such a statement were not possible, a similar
thing could be accomplished by a COMPILE_IF, but then a "compile bomb" 
would be needed to stop the compilation.  If neither of these checks are
made, the compiler will choke on various (possibly opaque) statments
in the code (if the general piece of software is a macro) or the
world model handler will give up because it can't fill in all of the
details needed in the world.  I guess that it is also possible that
the descrepancy may slip thru to runtime and cause the arm to move off
on its own to ???.


	We use ∂ without defining it.  ATTACH and ASSERT are used too
much before being defined.

	Never defined FRAME * VECTOR, but used it.
	RCB: Oops!  I want that to mean the same as TRANS * VECTOR, but
I've forgotton what the convention was going to be ... should change things
so they are consistent.

	Why do we use DEPROACH, APPROACH, and DEPARTURE?  It would
seem that the former precludes the others.
	RCB: I think there are two different things being refered to here:
(1) "USING APPROACH = AV" and "USING DEPARTURE = DV"    vs. 
"USING DEPROACH = DV"  ... in this case the single keyword DEPROACH is
definitely not sufficient to indicate which thing (approach or departure)
one wants to override.
(2) If the user wants to use the DEPROACH for some frame, how does he
refer to it?  The built-in way is DEPROACH(FRAME).  However, in the
examples, a pair of macros were defined (THE_APPROACH() & THE_DEPARTURE())
which simply extracted the appropriate DEPROACH.  I suppose that they
are confusing, since they are synonyms for DEPROACH().  I just liked
them so that I could remember what I was working with as I modified
approaches etc.  I could get rid of these if need be.


	Out of WITH, THROUGH, and USING, two can be eliminated.

	Switch description of ASSERT to active, to unfog who does
what when and with what effect. (p.36)

	Too much jargon in runtime overview, control structures.
(disappears, life, sprouts)
	LOU: I agree.

	
	do we distinguish upper and lower case?
	RF: No.  Our examples merely make a distinction to clarify
what is being used in a reserved way, and what has programmer-defined
semantics.
	RCB: In fact, I usually write comments in lower case to destinguish
them from the active code.

CONFUSION ABOUT FORCE AND FREE
	confusion about FREE.  Does it only free joints, or
directions? How about freeing about axis instead of in cardinal
direction?
	LOU: First specify a coordinate system then can specify
freedom along any axis or about any axis, need to specify coordinate
system as all directions of freedom must be orthogonal. Cannot
specify freedom along a stop monitoring direction, in fact stop on
force needs to fit into the same coordinate system. I believe that we
should bring up a system in which the hand, or any specifyable point,
move only in the free directions, not just freeing a joint. I also
believe that putting-on-the-record problem can be solved by freeing
not the hand but some point either above or below the hand, maybe.

	what does MOVE USING FORCE really do?
	LOU: This only makes sense when the hand is free in the
direction that the force would be exerted, then the hand does not try
to exert zero force in this direction but the specified force.

	Cannot reconcile USING FORCE with MOVE.
	LOU: See above.

	How can you force and free in the same direction?
	LOU: You can't. Speak to Bruce about all this stuff, and get
his ideas, don't just tell him how things should be.
	RCB: Couldn't we do that in the past ... that is, free the Z direction
and exert a force in the Z direction to make sure that the object conforms
to the table as it is being moved across it?

	Clearly FORCE and FREE are figments of Victor's arm, since
they must be in orthogonal directions related to direction of motion.
	LOU: They are figments of anything that forces or frees.
	RCB: They don't have to be orthogonal to anything.  They are currently
tied to a specific joint ... and everyone knows that's not optimum.
COMPLAINTS ABOUT PLANNING
	planning described in superficial way for very unstructured
environment.
	LOU: A remarkable sentence.

	world seems unstructured.  But manufacturing world is
structured.
	LOU: We make much of the structure in order to plan.
	RCB: I agree with Lou.  I don't understand where this comes from.

	not clear how many of the high level planning features will
be necessary.
	LOU: No it isn't.

	assymetry between planning and execution.  Seems that main
software activity is the planning; execution seems at a primitive
level.
	LOU: main work is at planning in order to translate tasks
into force and servo requirements. However the execution is hardly
"primitive"

	elaborateness of HAL seems premature.
	LOU: Once again I agree.
	RCB: To be seen.

	Asking system to choose proper oriention or task sequences
seems like unnecessary guessing game, if trained operator is present.
Utilize his experience.

	Why do COMPILE IF FACT (BLUE HOLDS ANYTHING) if can check a
globally known status word?


COMPLAINTS ABOUT EXECUTION

	execution phase not detailed except as "calles to external
devices" (p.3) That is, need to be able to interface low level
(sensors, devices) into control loop efficiently, as well as to
program its use.
	LOU: Yes all device need to be in control loop which is the
problem. This is why we don't want the SENSOR[47] type of syntax. Why
FORCE and FREE are good and Witneys (dont say I said so) feedback
stuff is no good as it leads to possible ossicilations, a thing that
the system can never let the user do as it could destroy the
manipulator.

	a higher control level should deal with visual systems, slow
sensors which cannot be put into control loop due to inefficiency.
	LOU: Not so the speed of light is quite fast and I hope that
Bob will show the way.
	ANON: Right on!!!

	predictor-servo cannot possibly operate fast enough to handle
intermittent contact with a solid object.  Only thing that allows
stability is passive accomodation of implementing hardware.
	LOU: Ah ha I told you Witney ossicilated!!!!


DISCOMFORT WITH THRUST OF LANGUAGE
	most information is absolute motions, locations, complete
object descriptions, instead of partial, relative, local.
	RCB:  Maybe the document is unclear.  But the system certainly
is designed to include relative (local) motions both explicitly and
implicitly;  explicitly, the user can specify the motion of an arm
with respect to that arm, another arm, an object, the table ..... 
implicitly, the user (thru the attachment graph structure) can make
a number of motions relative to some dynamically determined position.
What else would you like?
	I do not understand the complete vs. partial object descritpion
criticism.  The user can specify as much or as little as she likes
about `objects'.


	seems ultamate result will be a pseudo person who will see
scene, have imperfect joint servos requiring lots of searching,
discover unfelicitous conditions and correct them.  Seems to imply
need learning and generalizatin abilities.
	LOU: I still dont like searching and we will have more
trouble in this direction.

	our language stems from software-rich environment, with
cooperative assembly parts (specially made), and uncooperative arm.
But much of assembly and assembler machinery goes beyond that.
	LOU: At least we have an arm.
	RCB: I'm not convinced that a software-rich biase is bad.  One can
try new techniques and approaches more easily within software.  I agree
some of the tools and parts have been tailored for the arm, but I don't
think that negates the fact that the system can screw in real screws, etc.
Besides we don't expect to be able all assembly tasks from the start.

	How many levels does HAL have, anyway?  Which does this
manual describe?  Clear up all such references.
	RCB: Good question.  Levels might be:
			SERVO - RUNTIME LEVEL (execution-time concerns)
			EXPLICIT MOVE, CHECK, BRANCH LEVEL (within HAL)
			PSEUDO LEVEL UP ... using macros and procedures
			HIGH LEVEL PLANNING ... sequencing etc.

	Tendency to add new construct for each new situation.  Try to
get fewer, more powerful primitives.  -- JAF
	LOU: Everybody eliminate 17% of their constructs by thursday
ORDERING IN THE DOCUMENT

	should lay out the central philosophy of plan-then-move in
full at the beginning, not scattered.  Much of VHL belongs at
beginning too.
	LOU: This should all be in the Introduction, JAF thinks so
too.

	section 4.8 (library routines) seems out of place. Should be
moved earlier.

	Need lots of work on order of presentation.  Also some more
tutorial text on the world model, planning values.  -- JAF

QUESTIONS ABOUT SPECIFIC CONSTRUCTS, AND THEIR MEANINGS

	the tie-bars are invisible.
	RF: I don't understand this comment.
	LOU: I don't like "_" as it is too hard to type and leads Bob
to produce unrepeatable identifiers, the hashing function should do a
SWAP UUO everytime it sees one.
	R_C_B: I R_E_S_E_N_T T_H_A_T R_E_M_A_R_K !
	RCB: I obviously need to convince the XGP hierarchy that the
"_" deserves a bolder face in some fonts.

	What does ⊗ mean if two arms are in motion?

	Note that signal and wait are hardware primitives on
Unimates.
	LOU: and both systems plug into the same power lines.

	What happens in MOVE FROB if FROB is not attached?
	LOU: A user error meesage?

	Isn't USING DURATION ≥ 3 risky?
	RCB: Yes.  It is just approximate.  Currently there is no way
to do close coordination.  The signal and wait help, but again they are
approaximate.  Something should be added to help with this problem.  
For example, how do you move and screw at the same time?  !!!

	When is a symmetric attachment appropriate?

	What is a calculator expression?  (p. 37)

	Want to make UNITS follow scope rules -- JAF
	LOU: I think so too.
	LOU: NO SUCH PAGE ... THANK GOD